Subject: Recycle command for APPN ports and links

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Thu, 17 Oct 96 09:46:49 EDT

Our CMIP management application really does send a recycle command;
specifically, it sends a 'deactivate' action with a 'recycleParm'
parameter.  As I indicated before, this is not equivalent to sending a
'deactivate' and then following it with an 'activate', because it can be
used to recycle the port or link through which the management
communication itself is reaching the agent.  For other ports / links, I
think Bob is correct:  a 'recycle' command accomplishes the same thing as
a 'deactivate' followed by an 'activate' as soon as the port / link is
determined to in fact be inactive.

Given this, I wonder if the real question here isn't what does a
'recycle' do when the port / link is in a state other than active, but
instead what does a 'deactivate' do?  I suppose we can get into FSMs
if we have to, but my inclination is just to say that a 'deactivate'
results in the port / link ending up in the 'inactive' state,
regardless of what state it started in.  Similarly, an 'activate'
causes the resource to end up in the 'active' state.  Is this wording
going to be sufficient, or is there some subtlety here that I'm missing?

Bob Moore

> Sorry I'm a little slow responding to this...
> What action would an agent perform for a recycle if the port or link
> is in a state other than active?  I'd like to see this explicitly
> stated for inactive and pending states.
>
> Also, you could argue this function does exist today in this mib,
> by issuing deactivate, querying the state until inactive, then
> issuing an activate.  Given that most agents will require base code
> api changes to support recycle since usually the deactivate command
> will return before the link actually deactivated, a management
> application would probably need to support this method anyway.
> If you are prepared to have a manager and an agent support this,
> I'll agree to it but I want to make sure someone really thinks
> this is implementable.  I know the CMIP manager application has a
> recycle command at the user interface but does it really result in
> a recycle flow, or an inact/act?
>
> Bob Clouston
>
> >
> > In the course of implementing the appnPortAdminState and appnLsAdminState
> > objects, we've discovered that they provide less function than the
> > corresponding managed objects in our CMIP implementation.  Specifically,
> > they don't support the capability for a Management Station to recycle
> > (i.e., deactivate and then immediately reactivate) the port or link
> > station through which it is communicating with the agent.  Since
> > "recycle" is really a command rather than a state, we'd need to
> > reinterpret the objects a bit to introduce it.  With this in mind, as
> > well as Randy's request that we clarify the descriptions for these
> > objects, I'd like to propose the following:
> >
> > appnPortCommand OBJECT-TYPE
> >       SYNTAX INTEGER {
> >                       deactivate(1),
> >                       activate(2),
> >                       recycle(3),
> >                       ready(4)
> >                      }
> >       MAX-ACCESS read-write
> >       STATUS current
> >       DESCRIPTION
> >           "Object by which a Management Station can activate, deactivate,
> >           or recycle (i.e., cause to be deactivated and then immediately
> >           reactivated) a port, by setting the value to activate(1),
> >           deactivate(2), or recycle(3), respectively.  The value ready(4)
> >           has no meaning on a set operation; it is returned in response
> >           to a get operation if no set operation has been directed to
> >           this object."
> >
> >       ::= { appnPortEntry 2 }
> >
> >
> > appnLsCommand OBJECT-TYPE
> >       SYNTAX INTEGER {
> >                       deactivate(1),
> >                       activate(2),
> >                       recycle(3),
> >                       ready(4)
> >                      }
> >       MAX-ACCESS read-write
> >       STATUS current
> >       DESCRIPTION
> >           "Object by which a Management Station can activate, deactivate,
> >           or recycle (i.e., cause to be deactivated and then immediately
> >           reactivated) a link station, by setting the value to
> >           activate(1), deactivate(2), or recycle(3), respectively.  The
> >           value ready(4) has no meaning on a set operation; it is
> >           returned in response to a get operation if no set operation has
> >           been directed to this object."
> >
> >       ::= { appnLsEntry 2 }
> >
> > An agent that's unable to support recycling of a port or link station
> > could always indicate this fact via its AGENT-CAPABILITIES.
> >
> > What is the group's opinion on making this change to the MIB?
> >
> > Bob Moore, IBM Network Management Architecture
> >
>

---

From: Bob Clouston <[email-masked]>
Date: Thu, 17 Oct 1996 11:01:37 -0400 (EDT)

OK, I had missed your point that deactivating a link or port could
prevent the activate from reaching the agent.  
I'm OK with this.